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AN IMPROVED METHOD AND SYSTEM FOR CONDUCIING 
SECDRE PAYMENTS OVER A COMPUTER NETWORK 

SPBCIFICATrON 

mORTTY APPUC ATIQNS 
5 TWsappHcation claims priority to Uiuted States provisional 

application 6(V195,963, filed on April 11, 2000, and entitled TVlethod and System for 
Conducting Secure Payments Over A Computer Network," which is hereby 
incorporated by reference, and to United States application serial number 09/809367, 
filed March 15, 2001, and entitled '"Method and System for Secure Payments Over A 
10 Conq)uter Netwoik," also incoiporated by reference. 

BACKGROUND OF INVENTTON 
This invention relates to a method and system ifor conducting secure 
financial transactions ovw a communications networic and more particularly to a 
method and system for transmitting payments securely over a computer network, such 

15 as the Internet, and for transmitting Sensitive infomiation securely over public 
comniunication channels. 

As is self-evident, on-line commerce has experienced tremendous 
growth over the last few years but ev^ with that growth consumers are still troubled 
and concerned about using phonal financial information and transmitting such 

20 . kkfonnation) such as credit card numb^ andpepsonatidexitifie^oB numbers, over 
public communications networks, such as the IntemeL As a result, over the last few 
years, companies have struggled to find a way — the best way -* to ensure the security 
of pajrments made over a computer network and to decrease the risk of theft or misuse 
of financial information. 

25 For example, U.S. Pat^ No. 5,883,810 entitled "Electronic Online 

Commerce Card With Transaction Proxy Number For Online Transactions" and 
assigned to Microsoft Corporation, is directed to a system vrfiich provides for each 
transaction a temporary transaction number and associates it with the permanent 
account number, the transaction number looks like a real ca:edit card number and the 

30 customer uses that transaction number and submits it to the morhant as a proxy for 
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the customer account number. la this matta:, the custom^- does not have to transmit 
over a public network his or her real CTedit card number. 

In the *810 patent, the merchant passes along the transaction number to 
the issuiiig institution, which in tura uses the transaction number as an index, accesses 
the real customer account number and processes the authorization, sending the 
authorization reply back to the merdiant under the transaction number. As a result, 
risk is purpoitedly minimized not only because the customer only tranimi 
transaction numb^ but also because the proxy number is good only for a single - 
purchase - theft * Vould not greatly bmefit a thief because it cannot be repeatedly 
used for other purchases or transactions-*' Col. 2, lines 60-61 . 

Hiere is a need to improve vpojx the prior art systems and in particular 
there is a need for .a method and system for conducting a secure financial transaction 
over the Intern^ which avoids requiring the creation and transmission of a unique 
repeatedly g^en^ed transaction number to replace the transmission of the permanent 
account nimiber for each conducted transaction 

According to the iuvention of co-pending application 09/809,3 67, filed 
March 1 5, 2001, which is incorporated herein by referaice» a *^seudo" account 
number is assigned to a customer and cryptographically linked to a consumer's 
payment account numbd-. The payment account number is an account iiumber issued 
by a financial institution or other organization ttiat a consmner may use to make a 
payment for goods and/or services. For example, the payment account number may be 
the accouiit number from a payment card, such as a credit or debit card, or from a 
paym^ application, such as an electronic cash application stored on a consumer's 
computer. The pseudo account number £5>pears to be an actual payment accoimt 
number to a merchant That is, the pseudo account number has the same lengdi as a 
valid payment account number and begins with a vaUd identification number (e.g., a 
"5" for MasterCard International Incorporated ("MastaCard")). The pseudo account 
number is used by the customer instead of the real account number for all of his or her 
on-line financial transactions. 

According to the invention of the co-pending application 09/809,367, 
all transactions based on pseudo account numbers are preferably ciyptographically 
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authenticated using a secret key that is uniqae for each account number. The 
authentication may be based on the private key of a public-key pair C^ublic-key 
authentication'), or based on a secret key other than a private k^ C*secret-key 
au&entication"). Thus, ifunauthorizedpersons were to ascertain any pseudp account 
5 numbers, they would be unable to make fraudulent transactions using them. 

This syst^ can still be improved upon arid security can be further 
enhanced to protect the messages and information being transmitted during or in 
connection with a financial transaction being conducted over public communications 
lines. 

10 SUMMARY DFINVENTIQN 

Acconling to thepresent inv^ition, therefore, a method of conducting 
a transaction using a payment netwoA is pjovidedy in which a service provider 
receives a first authoiization request forthe.aiithorization of a transaction using a first 
payment account number, \^reia; 
15 0 the first payment account number has. a BIN 

code associated with the service provider, and is 
associated with a second paymmt account number 
having a BIN code associated wid an issuer of said 
second number; 

20 (ii) the first authoiization request includes an 

acquirer code associated with ah acquirer; and 
(iii) the first authorization request is rentable through 
the payment network to (he service provider based on 
the BIM code of the first payment account number. 

25 " The method fitrther includes having the service provide respond to the 

first authorization request by transmitting a second authorization request for 
authoiization of the transacdon using flie second payment account number, the second 
authorization request including an acquirer code associated with the service provider 
. aal being routable through the payment network to the issuer based on the BIN code 

30 of&e second payment account number. 
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AdditionaUy, a response to the second authorization request is received 
by Ifae service provider from the issuer, where the response includes the acquirer code 
associated with the service provider and is routable through the payment network 
based on diat code. A response to the first authorization request is then transmitted by 
5 th^ SCTvice provider to the acquirer based on the response to the second authorization 
request, and the response to the first aufliori2ation request prefer 
acquirer code associated with the acquirer and is routable through the payment 
network based on that code. 

Anotha: preferred mbodnnent of the mvention includes a method of 
0 conducting a transaction with a merchant using a first payment account number that is 
associated with a second payment account number, where the method con^rises: (a) 
generating a message authentication code based on one or moro transaction details; 
(b) transmitting at least the first payment account nvanb^ and the message 
authentication code to the merchant; (c) requesting by the merchant an autiiorization 
5 for payment of the transaction using the first payment account number, the request 
being formatted as if payment were t^dered at a point-of-sale terminal with a 
conventional magnetic-stripe payment card, the message authentication code being 
transmitted in a discretionary data field contained m a track of the type used in the 
magnetic stripe of said conventional paymoit card; (d) responding to tiie authorization 
) request for the first payment account number by requesting an authorization for 

payment of the transaction using the associated second paymmt account number, and . 
(e) accepting or decUning the autiiorization request for the first paym^t account 
number based on tiie response to the authorization request for the second payment 
account number and the message authentication code. 

BRIEF DESCRffTIQN OF TTTR PR AWTNG,^ 
Further objects, features and advantages of the invention will become 
apparent finom the following detailed description taken in conjunction with the 
accompanying figures showing a preferred embodiment of the invention, on which: 

FIG. 1 is a block diagram of tiie system for obtainmg a secure payment 
.^pUcation firom a provider over the Internet in accordance with the invCTtiou; 
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FIG. 2 is a flow diagngn illustratitig the flow of infonnation between a 
cardholder and a merchant when conducting a secure payment over the Internet using 
the present invention; 

FIG. 3 is a flow diagram illustrating flie flow of infonnation between 
5 an acqulTCT, a service provider and an issuer, in accordance with the present invention; 

FIG. 4 is a flow diagram iUusttating the flow of mfoimation between 
an issuer, a service provider and an acquirer, in accordance with the present invention; 

FIG. 5 is a flow diagram illustrating the flow of communication 
between a merchant and an acquirer for purposes of settlement and clearing, in 
10 accordance with the present invention; 

Througjiout the figures, the same reference numerals and characters, 
unless otherwise stated, are used to denote Hke features, elements, components or 
portions of the illustrated embodiment Moreover, while flie subject invention will 
now be described in detail witii reference to the figure^s, it is done so incoimection 
1 5 with a preferred embodiment It is iot^ided thai changes and modifications can be 
made to the described ^bodiment without departing ftom the true scope and spirit of 
the subject invention as defined by the upended claims. 

DETAILED DESCRIPTION OF THE PREFERRED EMBQDTMRNT 
Ihilialization of the Secure Payment AppHcadon 
20 In accordance with a preferred embodiment of the invention, a service 

provider issues, maintains and/or processes several components, including a secure 
payment application C*SPA"), of the secure payment system to be conducted in 
accordance with the techniques of the present invmtion. 

Figure 1 illustrates first how a cardholder with a financial transaction 
25 card may obtain a secure paym^t application from the service prx)vider 1 0 over the 
latemet, according to an exemplary embodiment of the present invention. It should 
initially be understood that a physical card is not necessary to utilize and obtain the 
benefits of tih.e invention^ but that only an account number be issued to a holder (in 
this case a cardholder) which identifies and links a user or participant to an account 
30 for purposes of coixductii^ a financial transaction. The cardholder may contact a web 
server associated with the sarvice provider using any appropriate device that may 
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commumcate over the Internet, such as a computer, cellular phone, or a personal 
digital assistant (PDA). For. the purpose of simplicity in the following discussions, it 
is assumed that the cardholder uses a computer to comnumicate over the Jntemet 
As shown in Fig. 1, the service provider, for example MasterCard 
5 International Incorporated {or an agent of MasterCard), has in its control one or more 
physically secure security modules 12, which offer physical protection for the 
' information stored inside the modules. These security modules each contain one or 
more "derivation keys" that are used to create and re-creale account-unique secret 
cryptographic keys, as explained below, which are provided within the secure 
10 payment ^plicatiotL 

First, in accordance with a preferred embodiment of the invoition, the 
cardholder must obtain an SPA from the service provider. The preferable steps for 
. downloading and mitializing the secure payment application (SPA) inchide: 

1 . The cardholder contacts the service provider's web site via the Internet (edtiier 
1 5 directly or throii^ a hyperlink to the web site through another web site, such 

as an issuer's web site. 

2. The cardholder provides, under SSL encryption geiiCTally known to those 
skilled in the ait, (a) a payment card account numbef, (b) a card expiration 
date, and (c) card auth^cating informatioDL The card auth«iticating 

20 information may include, for example, the card's CVC2 value, which refers to 

a three or four digit value that is printed next to the signature panel of some 
cards. This value is g^erated by the issuing bank using a secret 
cryptogr^Mc key and can be verified using this same key* 

3. The service provide may confirm the legitimacy of the card account number 
^5 and the card expiration date by obtaining a zero amount authorization from tiie 

issuer of the cardholder's payment card For instance, MasterCard may obtain 
this authorization over its Banknet™ communications network. 

4. The service provider may verify the CVe2 value if the issuer of the 
cardholder's payment card has provided the SCTvice provider with the 

0 cryptx)gr?qihic key(s) for verifying the CVC2 value. 
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5. The service provider may verify othra" card auth^ticatirig infonnation by 
sending such information to the issuer for verification. 

6. After flie service provider ("SP") has confirmed the legitimacy of the 
cardholder-provided card data, the SP creates or selects a pseiido account 

5 number and a secret key and embeds these data elements into a secure 

payment software application that is made available to the cardholder for 
download ova- the Internet prefwably under SSL encryption. 

The pseudo account number has as its BIN a special BIN reserved for 
pscudo accomit numbers. The remainder of the pseudo account numbCT is a value that 
10 can be translated by the senace provider via a table look-up process to the '"real" 
account number. 

Preferably, the assigned special service provider BIN may be one fiom 
a set of many such special BINs, where each BIN may correq)ond to a particular 
country or region and/or to a particular product within a country or region. Thus, the 
15 assigned special BIN may be flie one that corresponds to the country and/or the 
product of the submitted "real" account number. 

The secret key that the service provides preferably embeds in an SPA 
is unique for each card account number and is preferably derived within a security 
module using the card account number and a derivation key. This derivation key may 
20 itself be derived within the same or another security module usiiig a higher-level 
derivation key. 

The cardholder may provide a password to ttie service provider prior to 
downloading the secure paym^it appUcation or may select a password when the 
secure payment q)pUcation is being installed on the cardholder's computer. If a 

25 password is provided or selected, the cardholder will thereafter be required to ent^ 
this password in order to activate the secure payment application. The password 
selected by the cardholder may be used to encrypt the secret key included in the SPA 

As would be recognized by those skilled in the art, die SPA may be 
downloaded as part of a digital wallet appfication. In addition to the SPA the digital 

30 wallet may store a cardholder's personal infonnation and other applications, such as a 
purse apphcalion. 
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Generating Caid-Umque Secret l^eys 
The following steps may preferably be perfonned within a security 
module 12 controlled by the service provider or one of its agents to obtain a card- 
unique secret key to be included in the secure payment application. The following 
5 steps assume that the cardholder's payment card has a 1 6-<iigit account number and 
that the Data Encryption Algorithm (DBA) known to those, skilled in the art, with a 
double-lengfli key is used. The DBA is a U.S. Government standard oyptognqduc 
algorithm that is described m Fedwal Information Processing Standard (FIPS) 46- 1 , 
which is incorporated herein by reference in its entirety. The DBA is also defined in 
10 the ANSI standard X932, which is also incorporated herein by reference in its 
entirety. 

It is also assumed that the security module holds a secret higb-level 
key called the derivation key that consists of 16 bytiea and is used wifliinany or ail 
card account numbers to cryptographically compute a card-unique secret key, called 
15 the Per-Card Key, givoi the cardholder's 1 6-digi t payment account number. The 
derivation key may be unique for each country or for each special bank identification 
number or BIN. 

Preferably, the steps are: 

1 . Considering the payment account number as 1 6 binary-coded-decimal digits 
20 of 4 bits each, DEA-encrypt these 64 bits using as the encryption key the left- 
most 8 bytes of the 16-byte Derivation Key. 

2. DBA-decrypt the result of Step 1 using as the decryption key the rightist 8 
bytes of the 16-byte Derivation Key, 

3 . DE A-enciypt flie result of Step 2 using as the encryption key (again) die leja- 
25 most 8 bytes of the 1 6-byte DOTvation Key. 

4. Use the result of Step .3 as the left-most 8 bytes of die unique Per-Card Key. 

5. DBA-encrypt the result of Step 3 usmg as the enayption key the left-most 8 
bytes of the 16-byte Derivation Key. 

6. DBA-decrypt the result of Step 5 using as the decryption key the right-most 8 
30 bytes of the 16-byte Derivation Key, 
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7. DEA-enctypt the result of Step 6 usii^ as the encryption key (again) the left- 
most 8 bytes of the lfr*yte Derivation Key. 

8. Use ttie result of Step 7 as the right-most 8 bytes of the 1 6-byte unique Per- 
Card Key, and place this key m the secure payment application in such a way 

5 diat it will not be disclosed during the normal operation of this application. 

CoiTmiunication Betweoi Cardholder and M&rchant 
Fig. 2 iUustrates the flow of information between the cardholder 14 and 
merchant 16 when conducting a secure payment over tiie Memet according to an 
exemplary ranbodiment of ttie present invention, 
10 Once the SPA has been installed on a cardholder's computer, the 

cardholder preferably uses the SPA for all Intemet payments and the SPA provides 
the cardholder's pseudo account number for all Internet transactions. 

Once a cardholder has indicated a desire to conduct a transaction, it is 
desirable (but not essential) that tiia m^chant pass to the cardholder's con^uter the 
15 following data elements: (1) the acqmrer BIN, (2) the MID (die merchant identifier as 
known to die acquirer), and (3) the date and time (GMT or equivalent) of the 
transactioa 

Preferably, the SPA uses its embedded, secret key to create aNlessage 
Aulhentication Code (MAC) relating to the transaction. For exanq)le, a MAC of 
20 approximately 8 decimal digits may be created on the following data elements: 

1. A transaption sequence number stored in the cardholder's SPA and 
incrementedbytheSPAwhenever it generates a MAC. This transaction 
sequence number may be, for example, six (6) decimal-digits in length. 

2. The acquirer BIN if received ftom the merchant, otherwise zeros (which may 
25 be, for example, 6 decimal digits). 

3. Hie MID. if received from the merchant, otherwise zeros (which may be, for 
example, 6 decimal digits). 

4. Date and time, to the nearest hour or minute (in GMT), if received JBrom the 
mm^hant, otherwise zeros (whidi may be^ for example^ 1 0 decimal digits). 
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5. The transaction amount, as displayed for the cardholder, and as normally 
included in the message from cardholder to merchant (which may be, for 
example, 8 decimal digits). 

Preferably, a m^hant is able to accept a fall Track- 1 image from the 
cardholder's cottq)Uter, jiist as if the.merchant were pn^ared to communicate with 
computers that include magnetic-stripe readers. (The Track-1 image refers to the data 
on track 1 of the magnetic stripe of a paym^t card,) Moreover, the merchant 
preferably is able to pass the Track- 1 data to the acquirer as if the transaction were a 
point-of-sale (POS) transaction. 

If the merchant can scccpt the fiiU Trade- 1 data, tiie MAC itself and 
the data elements upon which the MAC is based are placed in the Track- 1 
discretionary-data field. The pseudo account number is placed in the Tiack-l 
account-number field, and the card expiration date is placed.in the Track-1 expiration- 
date fifeld. 

By sending the MAC in the Track-1 discretionary-data field, many 
merchants will not need to make any changes to their systems and/or software 
because they can akeady handle POS transactions, which include Track- 1 
discretionary data. For other merchants, systems and/or software to handle POS 
transactions are readily available. 

If a merchant cannot acc^t the frill Track- 1 data, the SPA may send a 
conventional SSL paymwit message, except that the pseudo.account number is used . 
instead of the cardholder's "real" account number. The merchant then sends the 
transaction data to the acquire in the maimer that it normally does. In practice, 
during a transition period, the merchants that are not capable of handling POS 
transactions with Track-1 data might not be required to receive and handle MACs. 

. Instead of being sent in the Track-1 discretionaiy-data field, the MAC 
may also be sent in another format, in wiiich case merchants and acquirers may be 
required to change flieir systems and/or software to handle this other format. 

Upon receipt of flie cardholder's transaction message, the merchant 
formats a conventional authorization request for the acquirer. For those merchants 
fliat axe able to able to accept Track-1 data, this authorization request will be 

10 
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formatted exactly as if it originated from a POS terminal and will include flie Track-1 
data provided by the cardholder. 

Should a merchant initiate multiple authorization/clearing transactions 
for a cardholder transaction, preferably only the first of these transactions will include 
the Track-l data. The subsequent transactions wiU include only the pseudo account 
number and expiration date and may be considered mail-order-telephone-order 
transactions. This is tnie for aHrocuning payments and partial payments with 
multiple clearings. 

Acquirer Handling of Authorigatio n Request 
Fig. 3 illustrates the communication between an acquirer 18, service 
provider 1 0, and an issuer according to an exonplaiy embodimmt of the present 
inventiorL 

The presence of Track-l data in an Internet transaction should not 
adversely impact those acquirers who receive transactions from Internet merchants via 
conventional telephone lines, since such transactions will be formatted identically to 
transactionis from conventional pointrof-sale terminals. However, acquirdcs who 
receive -transactions via the Internet (and not conventional telephone) may need a 
"conversion box" that would deUvw transactions without Track-1 data xmchanged and 
would deliver transactions with Track-1 data ova: a diff^ent physical wire as if they 
had come from POS tenninals. The design of such a conversion box is well within 
the abiUty of a person of ordinary skill in tiie art. 

When an acquirer 18 receives an aufliorization request message from 
an Internet merchant 16, it looks }jp the issuer BIN in its BIN table. Li the case of a 
pseudo account number transaction, the ^ssu^* will correspond to a service provider- 
authorized processing facility 1 0, which will receive the request In the case of a non- 
pseudo or real account number, normal processing will take place. 

Some countries may have a special security-moduie-equipped facility 
that handles domestic transactions. Bach suqh domestic facility would pref^^ly be 
set iq3 only with the service provider's approval and would hold only the 
cryptographic keys and account-number conv^sion data for the country whose 
transactions it processes. In countries with such a domestic facility, all same-country 

11 
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transactions will be sent to this facility. This can also be done for individual banks in 
a country, if it is so desired. 

A domestic &cility to handle domestic transactions would be far more 
efi&cient than causing domestic transactions to go trough a central processing 
5 facility. 

Sgrvjgg f jcovid^ Han41mg Qf ftiQ AttthQTis^tion R^ost 

When the service provider receives the request, it determines from the 
issuer BIN whether the account number is really a pseodo account number and, if so, 
sends the transaction to a special system &r processing. This system translates the 

1 0 pseudo account nuinb^ to the "real" account numb^ using a table-lookup procedure. 
If the system determines that a Tr^k-1 image is included, it uses a security module to 
derive the ^ypropxiate Per Card Key for this card account number in order to verify 
the MAC. (The derivation of the Per Card Key is described above.) 

If the MAC is verified, the system then examines the BIN in the Track- 

1 5 1 discretionary-data area. If this is not all zeros, the system compares this BIN with 
the acquirer BIN of the transaction, and verifies that the date and time included in the 
Track- 1 discretionary-4ata area are reasonable (taking into consideration that the 
merchant may batch its transactions and obtain delayed authorizations). The system 
also vCTfies that the authoiization request amount does not exceed the transaction 

20 amount in the Track- 1 discretionary-data aiea (the amoiint as ^proved by the 
cardholder) by more than a specified amotmt (e.g., 20%). 

It is possible that an acquirer may include the MID in the Acquire 
Reference D.ata (which is also called the Acquirer Reference Number). It is assumed 
that the 23-digit Acquirer Reference Data includes a mandatory 'transaction type" 

25 indicator and a mandatory acquirer BIN, but that the remaining digits are for the 
acquirer's discretionary use and may in some cases include the MID. The service 
provider may obtain from its Internet acquirers an mdicatton of which acquirers 
incliuie the MID in the Acquirer Reference Data, and if so, where m the Acquirer 
Reference Data they include it In the case of such an acquirer, if the Track- 1 image 

30 includes an acquirer BIN (rather than six zeros), the service provider system may also 
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verify that the ME) in the Track-l discretionaiy-data area matches ihe MID in flie 
Acquirer Reference Data, 

The service provider system may store a history of transaction 
sequence nmnbers (TSNs) for comparison with transaction sequence numbere in 
authorization requests. The comparison may be triggered by some condition, such as 
when the Track-l amount exceeds some specified threshold (e.g., $200). Such a 
threshold may be low^ when the Tract I image does not include an acquirer BIN. 
When the comparison is trigga^ed, the system may conqiare the transaction sequrace 
number included in the Track-l discretionaiy-data area against the stored history of 
transaction sequence numbers for the relevant card account immber. If the transaction 
sequence number of the cuaoit transaction is 1) higher than the smallest stored value 
for the current account number and 2) docs not inatch any stored value for this 
account, there is a reasonable assurance that the current transaction is not the 
fiBudxdent replay of data fiom a previous legitimate transaction. 

The stored history of TSNs may be limited to a predetennined number 
of TSNs. For example, the systm might store only the last 10 transaction sequence 
numbers received for a particular card account number. In addition, the verification 
of transaction sequence numb^s need not occur in real time. It may occur while the 
system is obtaining an authorization from an issuer. 

The purpose of these checks is to make it very difficult for wrongdoers 
who operate in collusion with Internet merchants and who may be able to obtain 
unencrypted transaction data to fiaudulently replay data from legitimate transactiohs. 

Once the service pro\dder system has completed the above-described 
verification processes (with the possible exception of the transaction sequence number 
verification), the system formats an authorization request message for the issuer 20. 
This message includes the "real" account number and e^qjiraidon date, but excludes 
flieothw Track-l data, Ite system replaces the acquirer BIN with one of the special 
BINs that serves as a "pseudo" acquirer BIN. The acquirer BIN is replaced so that the 
issuer responds to the service provider instead of the acquirer. 

In order for die acquirer and issuer to confute interchange fees 
'Xirrectly, the pseudo acquirer BIN should preferably correspond to the country in ' 
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which the acquirer is located or to anodier country or region that will provide the 
same resultant interchange fees. If each ooxmtry has a special BIN associated with it, 
the service provider may replace the acquire BIN with the special BIN associated 
witih tiie acquirer's countiy. If an acquirer's country does not have a special BIN 
5 associated with it, a special BIN associated with another country may be selected that 
results in the same interchange fees. 

The service provider stores in a database the Acquirer Reference Data 
received in the authorization request from die acquirer (hereinafter referred to as the 
"original Acquirer Reference Data**). In formatting an authorization message for the 

10 issQ^, the service provider preferably replaces the original Acquirer Reference Data 
vwth "pseudo** Acquire- Reference Data that includes the pseudo acquirer BIN, aa 
^ropriate transaction-type indicator, and an index value that the service provider 
can use to find the origmal Acquirer Reference Data. 

When a domestic facility processes a pseudo-account-numb^ 

15 transaction, it operates as described above. Preferabfy, however, this domestic facility 
will process only transactions for domestic issuers, and therefore will need only the 
cryptographic keys and account-numb^ conv^on tabic entries that apply to that 
country. 

bgu^ Hafl41ing Of Auth<;^risatiQn R^ggt 
2& Pig. 4 illustrates the conmiunication between the issuo- 20, the service 

provider 10, and an acquire 18 according to an exe£iq)lary embodiiuent of the present 
invention after the issuer has received an authorization request from the service 
provider or iiom an authorized domestic processing faoiUty, 

The issuer 20 authorizes the transaction just as it would any other 
25 transaction. It sends the authorizatioh response back to the "pseudo'* acquirer BIN, 
v^ch will be eith^ a service provider facility or a facility authorized by a service 
provider. 

When the service provider 10 receives an authorization response from 
an issuer, it examines the acquirer BIN to determine whether it is a "pseudo** acquirer 
30 BIN. If so, the service provider determines that the authorization response 

coiTeq)onds to a pseudo account number transaction that must be "restored" to its 
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original fonnat. Thus, the service provider translates the '"real*' account number back 
to the pseudo account number, and restores the Acquirer Refeence Data that had been 
in the original transactioiL The service provider then transmits the resulting message 
to the '*real" acquirer, which processes the transaction normally and sends flie 
5 authorization response to the merchant in the nonnal way. The merchant responds to 
the authorizatiou response as it would for any other transaction. 

Settlement a nd Clearing 
Figure 5 illustrates the flow of communication between a merchant 16, 
an acquirer, service provider or payment processor, for example, MasterCard's 
10 Banknet, and an issuer for the purpose of setttement and clearing according to an 
exemplary jsmbodiment of the present invention- 

A clearing message is processed essentially in the same manner as an 
authorization request message. As previously described, the acquirer 18 (because of 
entries in its BIN table) automatically routes a clearing message using a pseudo 
15 account number preferably to the service provider 10 or payment processor. At this 
facility, the pseudo account nuitiber is rq)laced by the *^eal" account number, the 
acquirer BIN is replaced by the "pseudo" acquire BIN, and the nanainder of the 
Acquirer Reference Data is rq>laced by an index that the service provider can 
subsequently use to obtain the ori:ginal Acquirer Reference Data. The clearing 
20 message with these changes is transnutted to the **real" card issuer 20, which. 

processes the transaction m &e nonnal way. If the acqmrer h^ip^ to also be the 
issuer, the service provider returns the cleared transaction to the acquirer with the real 
account number and proper fee calculations. 

Exception ProcessiTig 

2^ When a message about a transaction must be trananitted back to the 

acquirer or merchant from an issuer, the message is processed by the issuer as it 
normally would process any transaction message. Since the transaction as known to 
ihe issuer includes the "pseudo" acquirer BIN, the 'pseudo" acquirer BIN will cause 
the transaction message to be routed to a service provider fecility. At this facility the 

30 '•real" account number is replaced by the pseudo account number, and the pseudo 
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Acquirer RBference Data is replaced with the original Acquira Reference Data. The 
transaction message is tiien routed to the acquirer, which processes it like any other 
such transaction message. 

Issum ce of Plastic Cards for Identification 
5 In some situations, a cardholder may buy a ticket over the Internet and 

will be required, upon showing up at the evait to which the ticket grants admission, to 
produce the card used in the transaction in order to authenticate rightful possession of 
the ticket. 

To accommodate such situations, the service provider may issue and 
10 mail physical plastic cards to cardholders vAio obtain pseudo accoxmt numbers for 
Internet use. These cards would clearly indicate 'Tor identification purposes only, not 
vaHd for transactions" on them. The embossed and encoded account number would 
be tibe pseudo account number, though the CVC2 may be that of the **real" payment 
card 

15 As another alternative, those merchants that have a legitimate need to 

authenticate a cardholder using a pseudo account numb^ may register with the 
service provider (by providing to the savice pro\ider q)propriate idoitification and 
authentication infonnation), and the merchants will be provided with a secret key or 
certificate as cryptographic proof Of their registration. Thereafter, such merchants 

20 may obtain •'real" accoimt numbers fiom a service provider facility by providing a 
copy of the pseudo-accoimt-number trjmsaction details under OTptographic 
authentication Biat authenticates both the tamsaction data and the m^hants' right to 
obtain a **real" account number. The Service provider may tivsa forward the **real*' 
account numbers in encrypted form to the merchants, so that the cardholders may be 

25 identified with the cards corresponding to their *Veal" account numbers. 

Advantageously, the present invention provides enhanced security for 
the use of payment account numbers over the Internet. 

The foregoing merely illustrates the principles of the invention. It will 
thus be appreciated that those skilled in the art will be able to devise numerous 

30 systems and methods which, althou^ not explicitly shown or described herein, 
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embody the principles of the invention and thus within the spirit and scope of the 
invention. 
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CLAIMS 

1 . A method of conducting a transaction using a payment network, 
conq}rising: 

(a) receiving by a searvice providfa* a first authorization request for the 
5 authorization of a transaction using a first payment account number, wherein; 

(i) the first payment account number has a first BIN 
code associated with the service provide and is 
associated with a second payment account number 
having a second BIN code associated with an issuer of 

1 0 said second numbra:, said second paym«it account 

number not being included in said first authicmzation 
request-, 

(ii) the first authorization request includes a first 
acquirer code associated with an acquirer; and 

1 5 (iii) the furst authorization request is routable Qirough 

the payment network to the service provider based on 
said first BIN cod^ 

(b) responsive to the first authorizatioii request, transmitting by the service 
provider a second auftoiization request jfor authorization of the transaction using the 

. 20 second payment account number, the second authorization request inchiding a sepond 
acquirer code associ^ed with flie service provider and bdng routable through ttie 
payment network to the issuer based on said second BIN code; 

(c) receiving a response to the second authorization request by the service 
provider &om the issuer, flie response including the second acquirer code and being 

25 . routable through the payment network based on that code; and 

(d) transmitting a response to the first auQiorization request by the service 
provider to the acquirer based on the response to the second authorization request, the 
response to flie first authorization request including the first acquirer code and being 
routable through the payment netwo± based on that code. 
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2. The meliiod of claim 1 , wherein said response to the second 
authorization request from the issuer further includes said second paymecit account 
number, and said response to the first authorization request by the service provider 
further inchides said first payment account number. 

5 3 . Hie method of claim 1 , wherein said first authorization reiquest 

conq)rises a message aulfaeatication code including transaction data, and said request 
is fonhatted with a standard track having a plurality of fields including a discretionary 
field in which said message authentication code is placed. 

4. The method of claim 3, wherdn said service provider v^ifies the 
10 message authmtication code. 

5 . A mefliod of conducting a transaction with a merchant ovqt a 
communications network using a first paym^ account nttmber that is associated with 
a secoiad pa^on^t account numb^, the method con^>rising: 

(a) generating a message auth^tication code based on one or more 
IS transaction details; 

(b) transmitting at least die first payment account number and the message 
authentication code to the merchant; 

(c) requesting by the merchant an authorization for payment of the 
transaction u^ing the first payment account number, the request being formatted as if 

20 payment were tendered at a point-of-sale terminal with a conv^ttonal magnetic-stripe 
. paymait card, the format having a track wifli at least a discretionary data field and 
said message authentication code being transmitted in said discretionaiy data field; 

(d) responsive to the authorization request for the first payment account 
mmiber, requesting an authorization for payment of die transactiori using the second 

25 payment account number; and 

(e) accepting or dechning the aufhorization request for the first payment 
account number based on the response to the authorization request for the second 
paymoit account number and the message authentication code. 
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6. The method of claim 5, wherein said first and second payment account 
nmnbers include respective BIN codes, the first associated with a service provider and 
the second associated with an issuer of the second payment account nmnb^, said 
service provider receiving said merdiant's request through a payment network based 

5 on said first BIN code, and wherein said service provider generates said request for 
authorization of payment using the second payment account number and routes said 
request to said issuer throu^ said netwoik based on said second BIN code. 

7. Tlie mettiod of claim 6, wherein said service provider includes in said 
request for authorization for payment an acquirer code associated with said service 

10 provider, such that said response from said issuer is routed back to said service 
provider. 

8. The ihethod of claim 7, wherein said request by said mwhant includes 
an associated merchant acquirer code, and wh«:ein said service provider generates a 
message based on said accepting or declining step and routes that message to said 

15 associated merchant acquir er code. 

9. AmeAodof conducting a transaction over a coinmunicatiQiis network 
comprising: 

issuing by an issuer haviug an issuer BIN a first payment account number to 
a user having a computer^ said issuer BIN being associated with said first payment 
20 account number; 

providing a security module for gCTierating a secret key unique to each first 
account number issued; 

generating a second account number associated with said first payment 
account number, 

25 providing a secure paym^t ^plication by a service provider to said 

computer, said apphcation comprising said second account number and said secret 
key; 

storing said secure payment application on said computer; 
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selecting a merchaiit with >^oiji to conduct said financial transaction, said 
merchant having an associated acquirer BIN; 

passing to said cotDputer transaction data; 

generating a message auth^tication code based on said transaction data; 
5 transmitting track data to said merdiaat» said track data comprising said 

message authentication code and said second account number, 

gen^ting a fiist au^rization requ^ based on said data; 
transtnittiilg said first request to said service provide^ 
verifying said first request with said secret key, 
10 obtaining said first payment account number associated with said second 

account nxmiber, 

transmitting a second authorization request using said first psymesat account 
number to said issuer BIN associated with said number, and 
authorizing or rejecting said second request 

15 10. The method of claim 9, viierein said track data comprises a 

discretionary data field, an account number field, and an expiration date field, and 
wherein said transmitdng track data step fiirther includes 

placing said message authentication data in said discretionary data field; 
placing said second account number in said account number field; and 
20 placing an eviration date in said e}q)iration date field. 

1 L The method of claim 1 0» wherein said transaction data include said 
associated acquirer BIN, and a transaction amount 

12. The method of claim 1 1, wherein said verifying step fiulher includes 
verifying said transaction data. 

25 13. The metiiod of claim 9, wherein said second authorization request 

inchides an acquire: code associated with said service provider, and further 
comprising the steps of: 
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J generating a message based on said authorizing or rejecdng step; 

] forwarding said message to said sejvice provider based on said acquk 

code; and 

I . using said merchant's associated acquirer BIN to adv^ 



5 said message. 
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